
# 



APPLICATION 
FOR 

UNITED STATES LETTERS PATENT 



TITLE: ZERO OVERHEAD EXCEPTION HANDLING 

APPLICANT: JUDITH E. SCHWABE AND JOSHUA B. SUSSER 



"EXPRESS MAIL" Mailing Label Number EL079162532US 
Date of Deposit February 2. 1999 



# 



PATENT 

ATTORNEY DOCKET NO: 08993/009001 
Client No. : P3732 

ZERO OVERHEAD EXCEPTION HANDLING 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent disclosure as it 
appears in the Patent and Trademark Office patent files or 
records, but otherwise reserves all copyright rights 
whatsoever . 



10 




CROSS REFERENCE TO RELATED APPLICATIONS 
V. ( The\ following applications are incorporated herein 

Cby referenceXin their entirety: 

^^Obj ec\-oriented Instruction Set for Use with 
m 15 Resource-constraaned Devices" and "Token-Based Linking", 
■J each naming Joshua. B. Susser, and Judith E. Schwabe as 

5=c^ inventors, which ar^^ being filed concurrently with the 

p present application; >^d 

"Virtual Machin^^ with Securely Distributed Bytecode 
20 Verification", naming Mos^he Levy and Judy Schwabe as 
inventors, filed April 15,\l997. 

BACRC^OUND 

The present invention relates generally to object 
25 oriented computer software, and more specifically to data 

structures and runtime methods for minimizing stack storage 
requirements while supporting exception handling in a Java™ 
virtual machine implemented in resource-constrained devices 
such as smart cards and the like. 
30 A virtual machine is an abstract computing machine 
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generated by a software application or sequence of 
instructions which is executed by a processor. Programs 
executed on a virtual machine can be architecture-neutral. 
The term "architecture-neutral" refers to programs, such as 
5 those written in the Java™ programming language, which can 
be executed by a virtual machine on a variety of computer 
platforms having a variety of different computer 
architectures. Thus, for example, a virtual machine 
implemented on a Windows™-based personal computer system 
10 will use the same set of instructions as a virtual machine 

implemented on a UNIX™-based computer system. The result of 
the plat form- independent coding of a virtual machine's 
sequence of instructions is a stream of one or more 

f ^ . 

bytecodes, each of which is, for example, a one-byte long 

lie? 

fliJ 15 numerical code. 

f\ The Java programming language is an object-oriented 

1=5= programming language. In an object-oriented system, a 

M "class" describes a collection of data and methods that 

operate on that data. Taken together, the data and methods 
l3 20 describe the state of and behavior of an object. 

The Java programming language also is verifiable, 
ly which means that, prior to execution of an application 

W written in the Java programming language, a determination 

can be made as to whether any instruction sequence in the 
25 program will attempt to process data of an improper type for 
that bytecode or whether execution of bytecode instructions 
in the program will cause underflow or overflow of an 
operand stack. 

A Java virtual machine executes virtual machine code 
3 0 written in the Java programming language and satisfies "The 
Java™ Virtual Machine Specification", cited below. A Java 
virtual machine is designed for use with a 32 -bit 
architecture . However, various resource-constrained 
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devices, such as smart cards, have an 8 -bit or 16 -bit 
architecture , 

Smart cards, also known as intelligent portable 
data-carrying cards, generally are made of plastic or metal 
5 and have an electronic chip that includes an embedded 
microprocessor to execute programs and memory to store 
programs and data. Such devices, which can be about the 
size of a credit card, typically have limited memory 
capacity. The limited architecture and memory make it 

10 impractical or impossible to implement a Java virtual 

machine on the device. For example, some smart cards have 
less than IK of random access memory (RAM) and 16K of read 
only memory (ROM) . An example of a difficulty when 
implementing a Java virtual machine on a resource- 

15 constrained device arises in the handling of exceptions 
Referring to FIG. 1, in the context of computer 
programs written in the Java programming language, an 
exception handier 100 is a procedure (or a set of 
instructions within a procedure) that protects a specified 

20 set of program code, called a protected code block 102. 

When a Java program violates the semantic constraints of the 
Java programming language, the Java virtual machine signals 
this error to the program as an exception. The exception 
handler is executed whenever the applicable exception is 

2 5 "thrown" during execution of the corresponding protected 

code. The Java programming language specification states 
that an exception will be thrown when semantic constraints 
are violated and will cause a non-local transfer of control 
from the point where the exception occurred to a point that 

3 0 can be specified by the programmer. An exception is said to 

be thrown from the point where it occurred and is said to be 
caught at the point to which control is transferred. For 
instance, a particular exception handler, such as a 




procedure for handling "end-of -f ile" I/O errors, may be 
defined to be applicable to a particular portion of a first 
method 104. If the corresponding exception (i.e., an end- 
of- file exception in this example) results during execution 
5 of the protected code 102, execution of the exception 
handler 100 is initiated. Exceptions may be thrown 
implicitly or explicitly. Implicit exceptions are thrown by 
a Java virtual machine as a result of the execution of a 
program instruction, such as a null-pointer exception. 

10 Alternatively, an explicit exception is included within the 
body of a method using a Java "throw" statement. 

A thrown exception is said to be caught by an 
exception handler if there is an applicable enclosing 
exception handler for the thrown exception. An enclosing 

15 exception handler is one whose scope or range of applicable 
instructions includes the instruction that throws a 
corresponding exception. From the perspective of a 
particular instruction in a method, the set of enclosing 
exception handlers is the set of exception handlers whose 

20 range of applicable instructions (set of protected code) , 
includes the particular instruction. 

The Java programming language often refers to "try 
statements", "try blocks", "catch clauses" and "finally 
clauses" when referencing exception handlers. A try 

25 statement includes a try block, zero or more catch clauses 
and an optional finally clause. Exceptions are caught by 
enclosing code in try blocks. A try block is a portion of 
code to which a particular exception handler applies (i.e., 
the protected code block) . A catch clause defines an 

30 exception handler. A finally clause of a try statement 

provides a mechanism for executing a section of code whether 
or not an exception is thrown. In a Java program, a 
statement or expression is dynamically enclosed by a catch 



clause if it appears within the try block of the try 
statement of which the catch clause is a part, or if the 
caller of the statement or expression is dynamically 
enclosed by the catch clause. 
5 Whether a particular catch clause handles an 

exception is determined by comparing the class of the 
exception object that was thrown to the declared type of the 
parameter of the catch clause. The catch clause handles the 
exception if the type of its parameter is the class of the 
10 exception or a superclass of the class of the exception. 

Equivalently, a catch clause will catch any exception object 
that is an instance of the declared parameter type. 

If the protected portion of the first method 
% includes calls (called "invoke" instructions in The Java 

fiy 15 Virtual Machine Specification, referenced below) to other 

methods 106, which in turn may include nested calls to a set 
1=1: of further methods 108, 110, then end-of-file errors 

M generated by any of the methods 106, 108, 110 called 

directly or indirectly by the protected code 102 also will 
M 20 cause execution of exception handler 100 to be invoked. 
IZ However, nested method 112 can include its own end-of-file 

fy exception handler 114. If an exception is thrown when 

executing method 112, then exception handler 114 will be 
used to handle end-of-file exceptions caused by execution of 
25 instructions included in that particular nested method, as 
well as end-of-file exceptions caused by execution of any 
methods 116 called by nested method 112. 

In conventional Java programs, all the methods 
associated with an object class are stored together in a 
30 data structure called a class file, which is defined in The 
Java Virtual Machine Specification. Each method has its own 
exception table and furthermore the code of each method 
includes the code for the exception handlers referenced by 



its exception table. When a Java class file is created, all 
the exceptions associated with a method are arranged in a 
list, referred to as an exception handler table. Referring 
to FIG. 2, a conventional exception handler table 200 
5 includes one or more catch clauses (exception handlers) 202. 
Each catch clause 202 includes a start pc address 204 and 
stop pc address 2 06 that describes the Java virtual machine 
instruction range for which the exception handler is active, 
a type indicator 2 08 that describes the types of exceptions 

10 that the catch clause is to handle, and an address 210 at 
which execution of the exception handler code is to begin. 

The order of the catch clauses in the exception 
handler table is important. The throwing of an exception 
results in a search by the Java virtual machine through the 

15 exception handler table. The Java virtual machine execution 
continues at a first matching catch clause. Because Java 
code is structured, it is always possible to arrange all the 
exception handlers for one method in a single list. For any 
possible program counter value, this list can be searched to 

20 find the proper exception handler, that is, the innermost 
exception handler that both encloses the program counter 
(pc) value (where the exception was thrown) and can handle 
the exception being thrown. 

If there is no matching catch clause, the current 

25 method is said to have an uncaught exception. When an 

exception is uncaught, the execution state of the invoker, 
the method that invoked the current method (if any) , is 
restored. The propagation of the exception continues as 
though the exception had occurred in the invoker at the 

3 0 instruction that invoked the method actually raising the 
exception. 

Various runtime data structures are maintained by a 
Java virtual machine to keep track of the execution and 
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invocation of methods. A Java virtual machine can support 
many threads of execution at once. Each Java virtual 
machine thread has its own pc (program counter) register. 
The pc register contains the address of the Java virtual 
machine instruction currently being executed. Each Java 
virtual machine thread has a private Java stack, created at 
the same time as the thread. The Java stack stores Java 
virtual machine frames. The Java stack is equivalent to the 
stack of a conventional language such as C: it holds local 
variables and partial results, and supports method 
invocation and return. 

Referring now to FIG. 3, a conventional Java stack 
3 00 including a plurality of Java virtual machine frames 3 02 
is shown. Each frame 3 02 includes a reference 3 04 to a 
method and a return pointer 3 06. 

Reference 3 04 is a reference to the method that is 
currently executing, referred to as the current method. 
Reference 3 04 is used to indicate which exception handler 
table to search when an exception is thrown during the 
execution of the current method. Reference 304 may be of 
the form of an address at which the current method is 
stored. The code for each method typically includes the 
maximum stack space needed by the method, the maximum number 
of registers used by the method, the actual bytecodes for 
executing the method and a table of exception handlers. 
Reference 3 04 can point to the beginning of the current 
method where the exception handler table is typically 
stored. 

Return pointer 3 06 is a pointer to the method that 
invoked the current method, and more specifically to the 
location where execution is to resume in the invoking method 
at the completion of execution of the current method. 

As described above, smart cards and other resource- 



constrained devices typically include limited memory 
capacity. Accordingly, programs including a plurality of 
nested methods that require plural bytes to be stored on the 
Java stack may cause a stack overflow condition at runtime. . 
5 It is desirable to limit the information required to be 

stored in memory at runtime while allowing full support for 
conventional exception handling in a Java virtual machine. 

SUMMARY OF THE IWVEWTION 

10 In one aspect, the invention provides a computer 

implemented process for managing exceptions throwable during 
execution of methods in one or more classes by a machine. 
Each method includes an exception handler array defining 

7^ exception handlers associated with the method. The method 

|1J 15 includes combining the exception handler arrays for all 
methods into a single exception handler table. 

l2: Aspects of the invention include one or more of the 

M following features. All exception handler arrays for all 

methods in a class or all methods in all classes can be 

O 2 0 stored in the single exception handler table. All exception 
handler arrays for all methods in a Java package can be 

m combined in the single exception handler table. A method 

can be included in a class file. The step of combining all 

''^"^ exception handler arrays can include combining the exception 

25 handlers of all methods in a class file in the single 
exception handler table. 

The process can include searching the exception 
handler table when an exception is thrown while executing 
one of the methods, including locating a first matching 
30 exception in the single exception handler table. The 

searching step can include retrieving in order exception 
handler entries from the exception handler table, checking 
the type and range of each exception handler for the first 
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matching exception handler and stopping searching if a 
current exception handler does not match and is the last 
handler for the top most level of protected code in an 
associated method. 

All methods in a class are described in a single 
class file. The class files can be Java class files. The 
methods in one or more classes can be grouped in a package 
where the package includes a package data structure 
including first and second portions. The process can 
include storing the exception handler table in the first 
portion of the package and all methods in the second portion 
of the package . The step of combining can include 
concatenating the exception handler arrays including loading 
each exception handler array into the first portion of the 
package data structure in accordance with a predefined 
ordering. The predefined ordering can be determined based 
on the ordering of methods stored in the second portion of 
the package data structure . 

The machine can be a virtual machine implemented on 
a resource-constrained device. The resource-constrained 
device can be a smart card. The methods in one or more 
classes can be grouped in a package and the package can be 
installed on the smart card. The process can include 
creating a package where the package includes a package data 
structure including first and second portions. The process 
can include concatenating the exception handler arrays for 
each of the class files into a exception handler table, 
storing the exception handler table in the first portion of 
the package and all methods in the second portion of the 
package . 

In another aspect, the invention provides a method 
minimizing the amount of storage required for a runtime 
stack when executing a program. The runtime stack is 



maintained at runtime during the execution of the program 'by 
a machine for storing one or more frames where each frame 
includes a return pointer to an invoking method that called 
a currently executing method in the program. The method 
includes combining exception handler information for methods 
included in the program into a combined exception handler 
table and locating and searching the combined exception 
handler table when an exception is thrown during execution 
of one of the methods to locate the exception handler 
information without requiring the storage on the runtime 
stack of a pointer to the exception handler information. 

Aspects of the invention can include one or more 
features. The program can be a Java program. The machine 
can be a virtual machine implementing a Java virtual 
machine . The program can include a package of methods where 
the methods are in one or more classes. The virtual machine 
can be implemented in a resource constrained device on which 
the package is installed and executing. 

The method can include regis teri.ng the package in a 
registry service at installation. The registry service 
maintains a pointer and a range. The pointer indicates a 
location in the resource constrained device of the combined 
exception handler table associated with a given package. 
The range defines a range of addresses in the resource 
constrained device at which methods associated with the 
package are located. 

The step of locating can include locating a package 
associated with a currently executing method including 
comparing an address at which an exception was thrown 
against the range for each package registered in the 
registry service. The searching step can include searching 
the combined exception handler table associated with a 
located package. 



In another aspect, the invention provides a method 
of converting class files into a converted applet for 
execution on a resource constrained device and includes 
receiving one or more class files where each class file 
5 includes one or more methods. Each method includes an 
exception handler array defining exception handlers 
throwable by the method. The method includes defining a 
data structure for storing the methods and exception 
handlers for the converted applet including a first and 
10 second portion and defining an ordering for the methods and 
loading the methods according to the ordering in the second 
portion of the data structure. The exception handler arrays 
for all methods are combined in a single exception handler 

=j table. The exception handler arrays are ordered in the 

y 

y 15 table according to the ordering defined for the methods. 
1^ The method includes storing the single exception handler 

Z array in the first portion of the data structure. 

3 In another aspect, the invention provides a computer 

implemented process for managing exceptions throwable during 
20 execution of methods in one or more classes by a virtual 
machine. Each method includes an exception handler array 
defining exception handlers associated with the method. The 
individual exception handler arrays are combined and form a 
single exception handler table for two or more methods. The 
25 process includes searching the exception handler table when 
an exception is thrown while executing one of the methods 
including locating a first matching exception in the single 
exception handler table. 

In another aspect, the invention provides a computer 
3 0 system including instructions for causing the computer 

system to combine the exception handler arrays for methods 
into a single exception handler table. 

In another aspect, the invention provides a computer 
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system including instructions for causing the computer 
system to combine the exception handler information for 
methods in a program into a combined exception handler table 
and locate and search the combined exception handler table 
5 when an exception is thrown during execution of one of the 
methods to locate the exception handler information without 
requiring the storage on the runtime stack of a pointer to 
the exception handler information. 

In another aspect, the invention provides a computer 
10 system including instruction for causing the computer system 
to receive one or more class files. Each class file 
includes one or more methods and each method includes an 
exception handler array defining exception handlers 



throwable by the method. Instructions are included for 
m 15 causing the computer system to define a data structure for 
;P storing the methods and exception handlers for the converted 

il applet including a first and second portion, define an 

O ordering for the methods and load the methods according to 

'"^ the ordering in the second portion of the data structure, 

2 0 combine the exception handler arrays for two or more methods 
in a single exception handler table including ordering the 
exception handler arrays according to the ordering defined 
for the methods and storing the single exception handler 
array in the first portion of the data structure. 

25 In another aspect, the invention provides a computer 

system including instructions for causing the computer 
system to search an exception handler table when an 
exception is thrown while executing a method. Instructions 
are included to locate a first matching exception in the 

3 0 single exception handler table. 
Embodiments of the invention may include one or more 

advantages. The amount of information required to be stored 
on a runtime stack may be minimized while still supporting 
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conventional exception handling procedures. A concatenated 
exception handler table can be generated that includes 
entries for all exceptions associated with a package of 
methods for use in a resource-constrained device. No stack 
5 overhead is required to support exception handling. Once an 
exception is thrown, the Java virtual machine can 
efficiently search the concatenated exception handler table 
for the correct exception handler. With an optimization, 
the searching of the concatenated exception handler table 
10 can be efficiently implemented without requiring the 

evaluation of all of the entries in the concatenated table 
for certain classes of nested catch clauses. The table 
entries can be ordered to ensure a match searching 
'-'.^ termination at a top level handler. 

m 15 Other features and advantages will be readily 

apparent from the following detailed description, the 
l2 accompanying drawings and the claims. 



BRIEF DESCRIPTION OF THE DRAWINGS 
I3 2 0 FIG. 1 is a schematic drawing of a set of methods 

that are linked to each other at runtime by procedure calls. 
ni FIG. 2 shows conventional Java exception handler 

yp table including entries for each exception enclosed in a 

'"''^ method. 

25 FIG. 3 shows a conventional Java stack runtime data 

area. 

FIG. 4 is a schematic block diagram illustrating an 
exemplary system including a virtual machine residing on a 
smart card according to the invention. 
30 FIG. 5a is a flow diagram for a process of creating 

a concatenated exception handler table. 

FIG. 5b is a schematic block diagram for a method 
component data structure including all the methods for a 
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package to be executed on a Java Card™ virtual machine. 

FIG. 6 is a schematic block diagram of a 
concatenated exception handler table for a Java package. 

FIG. 7 is a schematic block diagram of an exception 
registry maintained by a Java Card virtual machine. 

FIG. 8 shows a runtime stack runtime data area 
maintained by a Java Card virtual machine. 

FIG. 9 is a flow diagram for a runtime method for 
searching a concatenated exception handler table. 

FIG. 10a is a flow diagram for an optimized runtime 
method for searching a concatenated exception handler table. 

FIG. 10b is a detailed flow of an implementation for 
the optimized runtime method described in FIG. 10a. 

DESCRIPTION 

A data structure and method for processing 
exceptions thrown during execution of a Java package on a 
resource-constrained device is described below. Resource- 
constrained devices are generally considered to be those 
that are restricted in memory and/or computing power or 
speed. Although the particular implementation discussed 
below is described in reference to a smart card, the 
invention can be used with other resource-constrained 
devices including, but not limited to, cellular telephones, 
boundary scan devices, field programmable devices, personal 
data assistants (PDAs) and pagers, as well as other 
miniature or small footprint devices. Such devices 
typically have limited memory capacity. For example, some 
smart cards have less than IK of random access memory (RAM) 
as well as limited read only memory (ROM) and/or 
non-volatile memory, such as electrically erasable 
programmable read only memory (EEPROM) . Similarly, some 
resource-constrained devices are based on an architecture 
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designed for fewer than 32 bits. For example, some of the 
resource-constrained devices which can be used with the 
invention are based on an 8 -bit or 16 -bit architecture, 
rather than a 32 -bit architecture. 

Referring to FIG. 4, development of an applet for a 
resource-constrained device, such as a smart card 40, begins 
in a manner similar to development of a Java program. In 
other words, a developer writes one or more Java classes and 
compiles the source code with a Java compiler to produce one 
or more class files 10. The applet can be run, tested and 
debugged, for example, on a workstation using simulation 
tools to emulate the environment on smart card 40. When the 
applet is ready to be downloaded to smart card 40, the class 
files 10 are converted to a converted applet (CAP) file 16 
by a converter 14 . The converter 14 can be implemented as a 
Java application being executed by a desktop computer. The 
converter 14 accepts as its input one or more export files 
12 in addition to the class files 10 to be converted. An 
export file 12 contains naming or linking information for 
the contents of other packages that are imported by the 
classes being converted. 

In general, the CAP file 16 includes all the classes 
and interfaces defined in a single Java package and is 
represented by a stream of 8-bit bytes. All 16-bit and 32- 
bit quantities are constructed by reading in two or four 
consecutive 8 -bit bytes, respectively. Among other things, 
the CAP file 16 includes a constant pool component 18 which 
is packaged separately from a method component 20. The 
constant pool component 18 includes several types of 
constants, ranging from numerical literals known at compile 
time to method and field references which are resolved 
either when the program is downloaded to the smart card 4 0 
or at the time of execution by the smart card. The method 



component 2 0 specifies the set of instructions to be 
downloaded to and subsequently executed by the smart card 
40, Further details of the structure of an exemplary CAP 
file 16 are discussed in co-pending patent Application 
5 entitled ''AN OBJECT-ORIENTED INSTRUCTION SET FOR USE WITH 
OTHER RESOURCE-CONSTRAINED DEVICES", by Joshua B. Susser et 
al., filed concurrently with the present application. 

In general, implementations and applets written for 
a resource-constrained platform such as the smart card 40 
10 follow the standard rules for Java platform packages. The 
Java virtual machine and the Java programming language are 
described in T. Lindholm et al . , The Java™ Virtual Machine 
Specification (1997), and K. Arnold et al . , The Java™ 

7^ Programming Language Second Edition, (1998) , which are 

fU 15 incorporated herein by reference in their entirety. 

Application card interface (API) classes for the smart card 
platform are written as Java source files which include 

M package designations, where a package includes a number of 

compilation units and has a unique name. Package mechanisms 

O 20 are used to identify and control access to classes, fields 

a and methods. 

ly As is described above, converter 14 accepts as its 

input one or more export files 12 in addition to the class 
files 10 to be converted and creates a CAP file 16. Each 

25 class file includes an exception handler table associated 
with each method for a given class. Converter 14 
concatenates all the exception handler tables for all the 
methods of all the classes associated with a package into a 
single exception handler table. The concatenated exception 

30 handler table is maintained with the underlying methods for 
the package and searched, as will be described in greater 
detail below, at runtime when an exception is thrown. 

Referring now to FIGS. 5a and 5b, a process 500 
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executed by converter 14 (FIG. 4) for concatenating 
exception handler tables for all methods in a package begins 
at step 502. An ordering for the methods in a package is 
defined (504) . The ordering defines the placement of the 
5 code for the underlying methods in an associated method 

component 550. For example, three methods 53 0, 535 and 54 0 
(Methods A, B and C) are included in a package 545. Each 
method includes code (531, 536 and 541, respectively) as 
well as an associated exception handler table (532, 537 and 
10 542, respectively). 

The method component describes each of the methods 
declared in a package. The exception handlers associated 
with each method are also described. In one implementation, 
the method component is represented by the following 



m 15 structure: 



method_component { 



w ul tag 

u2 size 

13 20 ul handlers_count 

except ion_handler_info 
ly except ion_handlers [handlers_count] 

=l3 method info methods [] 

.in — 



} 



TABLE 1: Method Component 

The tag item has a value that identifies the data 
structure as a method component. The size item indicates 
the number of bytes in the method component structure, 
30 excluding the tag and size items. The handler s_count item 
represents the number of entries in the concatenated 
exception handler table. The except ion_handlers item 
represents an array of 8-byte exception handler structures 
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arranged in a table, referred to as the concatenated 
exception handler table. Each exception handler structure 
represents a catch or finally clause defined in a method of 
the package. Entries in the concatenated exception handler 
5 table are sorted in ascending order by the distance between 
the beginning of the method component to the endpoint of 
each active exception handler range in the methods item. 
The ordering of blocks of exception handlers associated with 
particular methods in a package is discussed in greater 
10 detail below. 

The methods item represents an array of 
variable -length method info structures. Each entry 
represents a method declared in a class or interface of the 
given package . 

15 For purposes of the present application, method 

component 550 may be represented as a data structure that 
\^ includes two portions, first and second portions 552 and 

M 554. First portion 552 is a place holder for the exception 

handlers for all the underlying methods of the package. The 
P 2 0 exception handlers are stored in a concatenated exception 

handler table 556. The individual method code is stored in 
\li second portion 554. 

-^^ The individual exception handler tables are loaded 

into the concatenated exception handler table and ordered in 

25 accordance with the ordering defined by step 504 (506) . 
That is, each exception handler table for each method is 
loaded in block form into the concatenated exception handler 
table 556. The local ordering defined in each individual 
exception handler table for each method is maintained. In 

3 0 the example shown in FIG. 5b, the methods are ordered A, C 
and B, in second portion 554 of the method component after 
the execution of ordering step 504. The associated 
exception handler tables A, B and C are loaded in 
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13 20 methods) will generally order the exception handlers within 

each method so that the lower class exception handlers are 
llj positioned before the higher class exception handlers (where 

class rank is determined by position of the exception 
hierarchy) . Further, when there are two or more enclosing 
25 exception handlers for exactly the same exception condition 
that are applicable to an instruction that causes that 
exception to be thrown, a Java virtual machine executes the 
applicable enclosing exception handler established by the 
method closest in the chain of method calls to the method 
3 0 causing the thrown exception. 

After the individual exception handler tables are 
ordered and loaded in step 506, each exception handler entry 
in concatenated exception handler table 556 is converted to 
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concatenated exception handler table 556 in the same order 
(A, C then B) . The ordering of individual exception 
handlers in the individual exception handler tables 
satisfies conventional Java programming language constructs 
5 to assure a first match by a Java virtual machine at runtime 
is the most specific match that can arise. 

In one implementation, exceptions are organized in a 
class hierarchy. The exception class hierarchy has a 
highest exception class called "Throwable" and two main 
10 branches: a set of extraordinarily serious exceptions whose 
superclass is the "Error" class and a set of somewhat less 
catastrophic exceptions whose superclass is the "Exception" 
class . 

When an exception is thrown, a Java virtual machine 
15 executes the first exception handler found in a tree search 
of the enclosing exception handlers that is applicable to 
the thrown exception. To ensure that the lowest class 
enclosing exception handler applicable to the thrown 
exception is used, the authors of Java programs (i.e.. 
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an optimized data structure for use in a resource- 
constrained device, such as smart card 40 (FIG. 4) (508) . 
In one implementation, the data structure for an optimized 
entry in concatenated exception handler table 556 is shown 
5 in FIG. 6. Concatenated exception handler table 600 

includes a plurality of entries 602, each of which includes 
data in accordance with an exception handler information 
data structure. The exception handler information data 
structure includes a start offset 604, active length 606, 
10 handler offset 610 and catch type index 612. 

Start offset 604 and an end offset (not shown) are 
byte offsets into the particular method component. The start 
and end offset indicate the range in a bytecode array at 
which the exception handler is active. The value of start 
15 offset 604 must be a valid offset into a bytecode array to 
the opcode of an instruction. 

The end offset is defined as the sum of start offset 
604 plus active length 606. The value of the end offset 
either must be a valid offset into a code array of the 
^ 20 opcode of an instruction or must be equal to a method's 
y bytecode count (the length of the code array) . The value of 

n Start offset 604 must be less than the value of the end 

P offset. Start offset 604 is inclusive and the end offset is 

exclusive; that is, the exception handler must be active 
25 while the execution address is within the interval [start 
offset, end offset) . 

Active length 606 defines in bytecodes the range of 
instructions enclosed by the given exception handler. In 
one implementation, active length 606 is encoded to indicate 
3 0 whether the active range of the particular exception handler 
is nested within another exception handler, and more 
specifically, whether the current exception handler is the 
last handler in a list of exception handlers associated with 
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a particular protected code block. For programs written in 
the Java programming language, the bit is encoded to 
indicate if the current exception handler is the last 
handler (catch or finally clause) in a list of exception 
5 handlers for a protected code block. The high bit of active 
length 606 is set to one ("1") if the protected code block 
is not contained within another protected code block and the 
current handler is the last handler associated with the 
protected code block. The bit is set to zero ("0") if the 
10 protected code block is contained within another protected 
code block or the current handler is not the last handler 
associated with the protected code block. Where the 
encoding is used, the end offset is defined as the sum of 

O start offset 604 plus active length 606 and OxVFFF. 

15 Handler offset 608 represents a byte offset into the 

info item of the method component. More specifically, 
handler offset 608 indicates the start of the exception 

fj handler and a location at which point execution is to resume 

"'J by the Java virtual machine when the particular exception is 

20 caught. The value of handler offset 608 must be a valid 

ly offset into a method's bytecode array to an opcode of an 

instruction, and must be less than the value of the method's 

; y 

bytecode count . 

Catch type index 610 indicates the execution handler 

25 type. In order to transfer control to the exception 

handler, the pc associated with the thrown exception must 
fall within the range defined for the exception handler and 
be of the same type. If the value of the catch type index 
610 is non-zero, it must be a valid index into the constant 

3 0 pool table representing the class of the exception caught by 
this exception handler. If the exception handler represents 
a finally clause, the value of catch type index 610 is set 
to zero. A finally clause exception handler is called for 
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all exceptions that are thrown within the start offset and 
end offset range, irrespective of type. 

Referring again to FIG. 4, after conversion, the CAP 
file 16 can be stored on a computer- readable medium 17 such 
as a hard drive, a floppy disk, an optical storage medium, a 
flash device or some other suitable medium. 

The CAP file 16 then can be copied or transferred to 
a terminal 22 such as a desktop computer with a peripheral 
card acceptance device (CAD) 24. The CAD 24 allows 
information to be written to and retrieved from the smart 
card 40. The CAD 24 includes a card port (not shown) into 
which the smart card 4 0 can be inserted. Once inserted, 
contacts from a connector press against a surface connection 
area on the smart card 40 to provide power and to permit 
communications with the smart card 40. The terminal 22 also 
includes an installation tool or program 26 which loads the 
CAP file 16 and transmits it to the card 40. 

The smart card 40 has an input/output (I/O) port 42 
including a set of contacts through which programs, data and 
other communications can be provided. The smart card 4 0 
also includes an installation tool 46 for receiving the 
contents of the CAP file 16 and preparing the applet for 
execution on the card 40. The installation tool 46 can be 
implemented, for example, as a Java program and can be 
executed on the smart card 40. The smart card 40 also has 
memory, including volatile memory such as RAM 50 and non- 
volatile memory such as electrically erasable programmable 
read only memory (EEPROM) 54. The smart card 40 also has 
ROM such as ROM 52. The applet (CAP file 16) prepared by 
the converter 14 can be stored in EEPRROM 54 . 

As part of the installation process one or more data 
areas are created by the installation tool 46 to facilitate 
runtime operations. One example of a data area is an 



exception registry. The exception registry is a list used 
by a Java Card™ virtual machine when interpreting thrown 
exceptions . 

Referring now to FIGS. 4 and 7, exception registry 
700 can be a linked list data structure that is extendable. 
New entries may be added to the head of the list. Each 
entry 702 in exception registry 700 represents a method 
component 550 (See FIG. 5b) that contains exception 
handlers. Method components without exception handlers are 
not included. 

During installation of a CAP file, installation tool 
46 calls a Java Card virtual machine to register the method 
component associated with a package. Each entry includes an 
address 704 of the associated method component and its size 
706. Address 704 and size 706 define a range, with 
reference to the program counter (pc) , for instructions that 
are included in a package. The use of the exception 
registry is described in greater detail below. 

As described above in the Background, a Java virtual 
machine maintains various run-time data structures to keep 
track of the execution and invocation of methods. A Java 
Card virtual machine does the same. At runtime, a Java Card 
virtual machine maintains a pc and a runtime stack. A 
runtime stack stores Java Card virtual machine frames. 
Referring now to FIG. 8, a runtime stack 800 including a 
plurality of Java Card virtual machine frames 802 is shown. 
Each frame 802 includes a return pointer 806. 

Return pointer 806 is a pointer to the method that 
invoked the current method, and more specifically to the 
location where execution is to resume in the invoking method 
at the completion of execution of the current method. 

As explained further below, no reference to the 
method that is currently executing needs to be maintained on 



the runtime stack. All the exception handlers for all 
methods associated in a package are stored in a single 
concatenated exception handler table, which can be searched 
at runtime for an exception handler relevant to the current 
pc. 

Referring now to FIG. 9, a process 900 for runtime 
exception handling begins at step 902. A Java Card virtual 
machine either explicitly or implicitly throws an exception 
(904) . The class of the exception is determined (906) along 
with the pc position where the exception was thrown (908) . 

A search is performed in the exception registry to 
locate a method component that encloses the pc where the 
exception was thrown (910) . This determines in which 
package the method of the current frame is implemented. If 
no matching enclosing method component is found (and hence, 
no concatenated exception handler table) (912) , then a check 
is made to determine if a stack frame is available to pop 
off the runtime stack (914) . If no more stack frames are 
available to pop off the runtime stack, then the Java Card 
virtual machine is halted with an uncaught exception (916) . 
If another frame is available to be popped off the runtime 
stack, then the frame is popped (918) . The popping of the 
frame includes reinstating the previous frame and setting 
the pc to a new value, namely, the return location indicated 
by the return pointer stored on the runtime stack and 
associated with the previous frame. Thereafter, the process 
continues at step 910. The popping of entries off the 
runtime stack allows for nesting of methods among packages. 
That is, a method in a first package may be called (invoked) 
by an invoking method in second distinct package. As such, 
the invoking method is said to enclose the called method, 
and accordingly may include an exception handler that is 
applicable in the event the called method does not catch a 
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given exception. 

If an enclosing method component is located in 
searching step 910, then an entry in the associated 
concatenated exception handler table (the current 
5 concatenated exception handler table) associated with the 
method component is retrieved (in this case, the first 
entry) (930) . In one implementation, the starting address 
stored in the exception registry points to the address for 
the first entry in the concatenated exception handler table 
10 for the given method component. As such, the execution of 

the following steps may proceed directly after the retrieval 
of the starting address from the exception registry. 

The range associated with the current entry being 
□ tested is checked to determine if it encloses the pc where 

15 the exception was thrown (932) . If no match arises, then a 
next entry in the current concatenated exception handler 
table is retrieved at step 930. If no more entries are 
available (934) , then the process continues at step 914 
checking to determine if more stack frames are available to 
2 0 be popped as described above. 

If the range encloses the pc in step 932, then a 
check is made to determine if the type of exception 
specified by the exception handler matches the exception 
thrown (936) . The type matches if the type of exception 
25 thrown is of the same class as the specified class or a 

subclass of the specified class. A match also occurs if the 
exception handler corresponds to a finally clause. A 
finally clause is a Java programming language construct that 
allows a programmer to define an exception handler that will 
30 be executed for all class types and as such is a match for 
all types of thrown exceptions. If the type matches, the 
exception handler associated with the current entry is 
executed (938) and the process completes (940) . More 
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specifically, the pc is set based on the address stored in 
the current entry for the exception handler (handler offset 
610 from FIG. 6) and execution continues with the first 
statement of the caught exception handler. 

In one implementation, not all of the entries in the 
concatenated exception handler table are required to be 
tested prior to a determination that an uncaught exception 
has been thrown. Referring now to FIG. 10a, after the type 
test in step 936, an additional test is performed to 
determine if another enclosing try statement is included in 
the current method (937) . As described above, an enclosing 
try statement reflects another exception handler whose range 
also encloses the current pc. If no other enclosing try 
statement is present, then the process can immediately jump 
to the runtime stack popping step 914 irrespective of 
whether other entries in the current concatenated exception 
handler table remain to be processed. 

In one implementation, step 937 can be invoked using 
the optimization bit (the encoded high bit of the active 
length 605 item) stored in the concatenated exception 
handler table for the current entry. More specifically, the 
high bit of the active length for the current entry is 
retrieved (937a) . A check is made to determine if the bit 
is set (937b) . If the bit is not set (indicating that an 
enclosing try statement is present or that further handlers 
for the same try statement are present) , then the process 
continues at step 934. If the bit is set, then the process 
continues at step 914. 

While the present invention has been described with 
reference to a few specific embodiments, the description is 
illustrative of the invention and is not to be construed as 
limiting the invention. Various modifications may occur to 
those skilled in the art without departing from the scope of 



the invention as defined by the appended claims. 

The present invention is applicable to programs and 
methods written in programming languages other than Java, 
including programming languages that are compiled to 
platform dependent code. The techniques described can be 
applied in other contexts, for example to programs written 
in C or Pascal where similar runtime stack manipulations are 
required. 



What is claimed is: 



